Patrick Elliott <sel### [at] rraznet> wrote:
> Your solution **still** requires extra arrays, or code, or **some** way 
> to get the changing data "to" the object to transform it.

  Well, you have to define the objects somehow. You could as well
define them so that the transformations can be executed at each frame,
at *no additional cost*. The transformation code must exist in one form
or another.

> You keep claiming that you can just somehow "untransform" 
> the matrix

  Do you understand the concept of resetting a transformation matrix?
Or is that concept way too difficult for you to comprehend?

>, or change it later, even when doing something like 
> translate->rotate->translate irrevocably creates conditions where its no 
> longer as simple as just adding one new rotation.

  I don't think you even understand how transformation matrices work.
If you really think that an individual transformation couldn't be removed
from a transformation matrix even after several other transformations
have been applied to it, then you should *really* acquaint yourself with
transformation matrices and the math involved.

  In all these posts I haven't even been talking about removing/changing
one single transformation from the transformation matrix, but even that
is certainly possible to do to a transformation matrix, if you really
wanted to do so. (No, it's not possible to retrieve every individual
transformation which has been applied to a transformation matrix, but
if you already know which transformations has been applied to it, it is
possible to undo one of them. Anyways, that's not very relevant.)

> Some how you have to 
> both save memory "and" provide a way to change interdependent 
> transforms

  You don't understand this either, do you? The memory wasting comes in
your solution in that *every* object will have a useless array, wasting
memory, when none is needed.

  In other words, in your "solution" every object has a transformation
array *and* there exists SDL code which writes values to that array.
In the correct solution there's no such array and only the code exists.

  Do you understand now how there's less memory requirements in this way?

>, which, unless you are a fracking mathmatician, isn't going 
> to be practical.

  You don't need to be a mathematician to apply a series of transformations
to an object. It's just a question of syntax.

> any solution you come up with, at minimum, is going to 
> require some transforms to be user changable

  How does the current SDL handle transformations which change from one
frame to the other? Why should the new SDL be any different (except that
re-parsing the object itself can be skipped)?

> after the fact, and 
> keeping **all** of them in an array, to be applied later, is **worse** 
> that keeping all the of the initial states on the object, then just 
> changing the one you actually need to.

  Why is it worse?

  The only thing which is worse is your solution: You are hard-coding one
specific solution, and you are wasting memory by having a useless array
in each single object.

> I haven't seen any argument from you that does a thing to truly address 
> that issue.

  That's because you have a misunderstanding about how transformations work.

  Answer me this: Why the current POV-Ray doesn't need object-specific
transformation arrays?
  The answer is not "because it re-parses the objects at each frame".
That re-parsing could perfectly be skipped with the proper syntax changes.

-- 
                                                          - Warp

Post a reply to this message